Apparatus and method for monitoring and controlling access to data on a computer readable medium

ABSTRACT

The invention provides a device driver for monitoring and controlling access to data on a computer readable medium. The device driver comprises an interface for access to a device-driver stack for a media drive, a detector for detecting the insertion of a computer readable medium in said media drive, and a monitor for monitoring data transfer from said computer readable medium. The monitor evaluates a behavior characteristic of an application accessing data on said computer readable medium, and indicates when said behavior characteristic fulfills predetermined criteria. A control system is responsive to said monitor for issuing at least one control output when said behavior characteristic fulfills said predetermined criteria. The invention also provides a method of monitoring and controlling access to data on a computer readable medium by means of the device driver.

FIELD OF THE INVENTION

The invention concerns apparatus and a method for monitoring andcontrolling access to data on a computer readable medium, and isparticularly applicable to the protection of a data carrying mediumagainst unauthorised copying.

BACKGROUND TO THE INVENTION

Various techniques are known for protecting computer readable media,such as optical discs including CDs and DVDs, against unauthorisedcopying. Two such methods of protection are described in our earlierU.S. Ser. No. 10/848,879 and U.S. Ser. No. 10/939,186, both of which areincorporated herein by reference.

U.S. Ser. No. 10/848,879 discloses a method of protection in whichredundant control data, including errors, is included amongst the datacarried by an optical disc. The control data controls access to contentfiles on the optical disc, containing material or content data to beplayed, and the redundant control data is not utilized during normalplayback of the content. However, during unauthorized copying, theredundant control data is accessed and the errors in such data arearranged to frustrate navigation of at least one program path providingaccess to the content data.

U.S. Ser. No. 10/939,186 discloses a method of protection in which atleast one region containing unreadable or subversive data is providedwithin the content data on an optical disc. Control data on the disc foraccessing content files containing the content data ensures that accessto the region of unreadable or subversive data is prevented duringnormal playback. However, in the event of unauthorised copying, theregion of unreadable or subversive data is accessed and hinders orprevents copying.

The methods according to these two earlier U.S. patent applications areboth passive, in the sense that they rely on data incorporated in theoptical disc for protecting the disc against a procedure known as“ripping”, i.e. unauthorised copying onto a hard drive of a localcomputer or network.

Such passive techniques are effective to some extent in protectingagainst unauthorised copying. However, ripping software is becomingincreasingly sophisticated and powerful and increasingly effective inovercoming such passive forms of protection.

There is, therefore, a need for more effective forms of protectionagainst unauthorised copying and for forms of protection that are harderto circumvent.

SUMMARY OF THE INVENTION

It is an object of the invention to provide a means for monitoring andcontrolling access to data on a computer readable medium, whichovercomes the problems described above.

It is another object of the invention to provide a means forauthenticating an instance of use of a computer readable medium. Suchauthentication may be used to verify that the use of the medium islegitimate, as in normal playback, or to permit access to furtherapplication functions or other functions, or it may be used to prohibitunauthorised use of the medium, such as ripping.

It is a further object of the present invention to provide an effectiveapparatus and method for monitoring and controlling access to data on acomputer readable medium, which provides improved protection againstunauthorised copying.

It is another object of the present invention to provide apparatus and amethod for monitoring and controlling access to data on a computerreadable medium in the form of an active process installed on thecomputer, as opposed to passive data provided on the computer readablemedium.

According to a first aspect of the present invention, there is provideda device driver for monitoring and controlling access to data on acomputer readable medium, comprising: an interface for access to adevice-driver stack for a media drive; a detector for detecting theinsertion of a computer readable medium in said media drive; a monitorfor monitoring data transfer from said computer readable medium and forevaluating a behaviour characteristic of an application reading data onsaid computer readable medium; and a control system responsive saidmonitor for issuing at least one control output when said behaviourcharacteristic fulfills predetermined criteria.

According to another aspect of the present invention, there is provideda method for monitoring and controlling access to data on a computerreadable medium, comprising: accessing a device-driver stack for a mediadrive; detecting the insertion of a computer readable medium in themedia drive; monitoring data transfer from the computer readable medium;on the basis of the monitored data transfer evaluating a behaviourcharacteristic of an application reading data on the computer readablemedium; and issuing at least one control output when the behaviourcharacteristic fulfills predetermined criteria.

In the preferred embodiments described below, the evaluation is based ona behaviour characteristic comprising one of a volume or frequency ofdata transfer or a pattern of behaviour for accessing data on thecomputer readable medium.

In the case that either volume or frequency of data is evaluated, thenthe predetermined criteria may be a threshold value against which ameasured volume or frequency value is compared. In the case that apattern of behaviour is evaluated, the evaluation may be based on anavigation path for accessing the main content on the computer readablemedium. The predetermined criteria may then be a preset navigation pathidentified in control data included on the disc against which anavigation path for the data that is accessed on the disc is comparedfor a match.

The evaluation is preferably for the purpose of distinguishing betweenplayers who are accessing data on the computer readable medium forlegitimately playing the main content, and rippers who are accessing thedata for the purpose of illegitimately copying the same. In suchcircumstances, the control output serves respectively to permit orprohibit further access to the computer readable medium for furthercopying.

In addition or alternatively, the evaluation may be for the purpose ofauthenticating the user or the use of the computer readable medium forpermitting access to further functions.

In such a development of the invention, the control output may beemployed to control access to further functions on the computer readablemedium in the event that the evaluation has established that the user isa legitimate user.

The above techniques for protecting data on a computer readable mediumagainst unauthorised use may be thought of as active, in the sense thatthey rely on monitoring and controlling such use in real time. It is, ofcourse, possible according to the invention to combine such activetechniques with the passive techniques described above in relation tothe prior art.

The invention may also comprise a hook driver for enabling the devicedriver to hook into the device-driver stack for the media drive.

Advantageously, the invention also includes a fingerprint reader forchecking the computer readable medium on insertion into the media driveto establish whether it carries a fingerprint indicating that the mediumis protected against copying. If not, the invention preferably allowsdata transfer without performing any monitoring or evaluation.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is described further, by way of example only, withreference to the accompanying drawings, in which:

FIG. 1 is a block diagram of a computer incorporating the presentinvention;

FIG. 2 is a block diagram showing further details of the computer ofFIG. 1;

FIG. 3 is a diagram of a device driver stack of FIG. 2, showing a normalflow of information and a relationship between the stack and a hookdriver according to the present invention;

FIG. 4 is a further view of the device driver stack and hook driver ofFIG. 3;

FIG. 5 is a flowchart showing the steps of a hook manager for the hookdriver for hooking the hook driver into the device driver stack;

FIG. 6 is a flowchart showing the steps of a fingerprint reader of thehook driver for reading a fingerprint on an optical disc inserted into amedia drive of the computer;

FIG. 7 is a flowchart representing steps for data transferauthentication according to a first embodiment of the hook driver forevaluating volumes of data transfer from an optical disc;

FIG. 8 shows the navigation structure of data on an optical disc;

FIG. 9 shows the navigation sequence resulting from the navigationstructure of FIG. 8;

FIGS. 10 and 11 show respectively the navigation path for a legitimateplayer and the navigation paths for two different kinds of ripper inrelation to the navigation structure of FIG. 8;

FIG. 12 is a flowchart showing the steps for navigation pathauthentication according to a second embodiment of the hook driver basedon evaluating the navigation path;

FIG. 13 is a flowchart showing authentication steps for a thirdembodiment of hook driver employing content scrambling system (CSS)decryption; and

FIG. 14 is a flowchart representing steps for data transferauthentication according to a fourth embodiment of hook driver forevaluating frequency of data transfer from an optical disc.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The invention will now be described with reference to a number ofpreferred embodiments illustrated in the drawings. The invention may beemployed in a personal computer, a computer system comprising a localarea network (LAN) or a computer network comprising a wide area network(WAN), such as the Internet. The principles are the same in each case,and therefore only the application of the invention in a personalcomputer will be described. Such an application is illustrated in FIGS.1 to 4, which illustrate the basic hardware employed in the presentinvention and the corresponding architecture.

Referring initially to FIGS. 1 and 2, a personal computer 10 includes acentral processing unit (CPU) 12, a memory 14, and a hard disk 16. Thecomputer 10 also includes at least one media drive 20 for a computerreadable medium such as an optical disc, for example a CD or a DVD.Stored in the memory 14 is the application software for providinginstructions to the CPU 12 for a variety of functions. In particular, afirst such function 22 comprises a device driver stack for controllingreading and writing with respect to a computer readable medium, in thisinstance an optical disc, loaded in the media drive 20. A secondfunction 24 is a storage device driver stack for controlling reading andwriting in relation to the hard disk 16 of the computer 10. In addition,a further function 26 is stored in the memory 14, which comprises adevice driver according to the invention. This device driver 26 istermed a ‘hook driver’ herein because, in use of the invention, it hooksinto at least one of the device driver stack 22 and the storage devicedriver stack 24 in order to perform a monitoring function as will bedescribed below.

According to the invention, the hook driver 26 detects when an opticaldisc 28 is inserted into the optical drive 20, and thereafter monitorsthe use of the optical disc 28. In particular, the hook driver 26monitors data transfer in relation to the optical disc 28 and/or themanner in which the optical disc 28 is accessed, in order to determinewhether the data on the disc is the subject of normal playback by a playapplication 30 or unauthorised copying by a ripping application 32.During normal playback, the information is read from the optical disc 28by the player 30 by way of the device driver stack 22 for output by wayof speakers and/or a display. During ripping, however, data read fromthe optical disc 28 is copied by means of the ripper 32 and istransferred by means of the storage device driver stack 24 to the localhard disk 16. On detection of ripping by the ripper 32, the hook driver26 takes steps to prohibit access by the ripper 32 to the optical disc28 and/or to prevent further copying of data from the optical disc 28.

FIG. 3 shows details of the device driver stack 22 and the connectionbetween the hook driver 26 and the device driver stack 22. As shown inFIG. 3, the device driver stack 22 is situated at an interface 40between a user mode 42 of the computer 10 and a kernel mode 44. The usermode handles high level activities, such as the implementation ofapplications in the computer, including for example a Windowsapplication 44, the play application 30 or other applications requiredby the computer user. The kernel mode 44 handles low level activities,such as the scheduling of tasks, and interfacing with drivers etc.

The interface 40 is known as a small computer system interface (SCSI)and serves for example to connect hardware, such as the optical drive20, by way of the device driver stack 22 to the CPU 12 within thecomputer 10. Requests, known as SCSI requests, from the Windows or otherapplication 44 to the optical drive 20 are transmitted across theinterface 40 and through a series of layers in the device driver stack22, which increasingly convert the requests from a high level softwarelanguage to instructions applicable to the physical hardware in the formof the optical drive 20, for implementation at the optical drive 20.Completed SCSI requests are then transmitted in the reverse directionthrough the device driver stack 22 and across the interface 40 to theWindows application 44 for processing in the CPU 12.

As shown in FIG. 3, the device driver stack includes three layers in theform of a high level device object 46, a further device object 48,comprising in this instance a CD-ROM class driver, and a physical deviceobject 50 for converting the instructions from the CD-ROM class driver48 into signals for application to the optical drive 20. The hook driver26 is represented in FIG. 3 as a driver object 52, which hooks into thephysical device object 50 at the lowest access point of the devicedriver stack 22, in other words at the level of the device driver stack22 which interfaces with the hardware comprising the optical drive 20.The reason for situating the hook driver 26 (the driver object 52) aslow as possible in relation to the device driver stack 22 is in order tointercept requests or commands from all of the applications andprocesses that may wish to read the optical disc 28 in the optical drive20. Were the hook driver 26 to be situated at a higher level in relationto the device driver stack 22, it is possible that certain requests andcommands could be arranged to bypass the hook driver 26 and thereby tocircumvent the monitoring function provided by the hook driver 26.

FIG. 4 is a further view showing a slightly different representation ofthe device driver stack 22 situated at the SCSI interface 40 separatingthe user 42 and the kernel 44 of the computer 10 and arranged to receiverequests from the application 44. In this instance, the device driverstack 22 includes the CD-ROM class driver 48 located between upper andlower filter drivers 54, 56 respectively. The lower filter driver 56 isconnected to the physical device object 50, which applies requests tothe optical drive 20 by way of a hardware abstraction layer (HAL) 58.The HAL 58 serves for abstracting hardware signals from the requestsreceived from the physical device object 50 and applying them to theoptical drive 20 and for converting signals received from the opticaldrive 20 into completed requests for transmission back to the physicaldevice object 50.

The hook driver 26 as shown is hooked in to the physical device object50 of the device driver stack 22, and includes a hook manager 60 foreffecting the connection between the hook driver 26 and the physicaldevice object 50, a fingerprint reader 62, and an authentication object64. Further details of the hook manager 60, the fingerprint reader 62and the authentication object 64 will now be described with reference toFIGS. 5 to 7, which show flowcharts representing the steps performed byeach of these objects.

FIG. 5 is a flowchart representing the operations of the hook manager60, which are as follows. In step 500, the hook driver 26 accesses thephysical device object 50 and registers itself for receivingnotifications of plug and play (PNP) devices incorporated within thecomputer 10 or connected to the computer 10 as peripherals. Such PNPdevices include the optical drive 20. Next, in step 502, the hook driver26 requests from the operating system of the computer 10 and obtains alist of such devices currently present, including the optical drive 20.The request for notification of PNP devices in step 502 remains active,and as further devices are connected into the computer 10 the IDs forsuch devices will be supplied to the hook driver 26. Having obtained thecurrent list of PNP devices in step 502, the hook driver 26 in step 504substitutes its own function for the normal SCSI function provided bythe physical device object 50. All future SCSI requests will thereforepass through the hook driver 26. Thus, all future SCSI requests forsupply to the optical drive 20 will be directed through the hook driver26 as shown in step 506. In addition, in step 508, the hook driver 26registers itself with the application 44 for receiving notification ofmedia arrivals, i.e. notification that an optical disc 28 has beeninserted in the optical drive 20. Such notifications are now handled bythe hook driver 26 as indicated by step 510. The installation of thehook driver 26 is now complete.

FIG. 6 shows details of the steps involved in the sub-routine 510 inFIG. 5. When a notification is received in step 600 that a new opticaldisc 28 has been inserted in the optical drive 20, the hook driverchecks the optical disc for a content protection (CP) signature orfingerprint in step 602. The hook driver 26 enquires in step 604 whethera fingerprint has been found and, if the answer if yes, sets a flag “Isprotected” to true in step 606. If the answer to the enquiry of step 604is no, the hook driver sets the flag to “false” in step 608.

A first embodiment of the authentication device 64 will now be describedwith reference to FIG. 7. The present embodiment of authenticationdevice 64 is based on the assumption that the transfer of large volumesof data signifies that ripping is taking place rather than normalplayback. For example, such large volumes of data could be in the rangeof 10 megabytes to 10 gigabytes.

As shown in FIG. 7, in step 700, requests that hitherto would have beenprocessed in the device driver stack 22 are now received by the hookdriver 26. In step 702, the hook driver 26 enquires whether the requestthat has been received is a read request. If the answer is no, the hookdriver proceeds to step 704 and enquires whether the request is a writerequest. In the event that the answer is again no, the hook driver 26simply forwards the request to the optical drive 20 in step 706. If theanswer to the enquiry in step 704 is yes, signifying that the process isintending to write data of any kind to the hard disk 16, the hook driver26 proceeds to step 708 and obtains the ID for the process. Next, instep 710, the hook driver 26 begins logging in a write data log theamount of data written by the process and proceeds again to step 706.

Reverting to step 702, if the answer to the enquiry in this step is yes,namely that the request received by the hook driver 26 is a readrequest, the hook driver 26 proceeds to step 712 and checks whether theoptical disc 28 inserted in the optical drive 20 is protected againstcopying, by reviewing the flag generated in step 606 or step 608 of thesequence of FIG. 6. If the optical disc 28 is not protected, the hookdriver 26 once again proceeds to step 706 and simply passes the SCSIrequest directly to the optical drive 20. On the other hand, if theoptical disc 28 is protected, the hook driver 26 proceeds to step 714and obtains the ID of the process that intends to use the optical disc28. Next, in step 716, the hook driver 26 enquires whether the processis now reading video data from the video zone of the optical disc 28. Ifnot, the hook driver 26 assumes that the process is reading what isknown as bonus material on the optical disc 28, ie advertising,promotional or other such material that is not restricted againstcopying, and in step 718 begins logging in a read bonus material datalog the amount of data being read from such bonus material. A validplayer may copy the bonus material before starting normal playback andit is important not to block such activity. The hook driver thenproceeds to step 706.

If, in step 716, it is established that the process is reading videodata from the video zone of the optical disc 28, the hook driver 26 nextchecks in step 720 whether the process is already permanently blocked(as will be described), and in the event that the response is a yesproceeds directly to step 722. If the response to the enquiry of step720 is a no indicating that the process is not blocked, the hook driver26 proceeds instead to step 724 and enquires whether the process readingfrom the optical disc 28 has exceeded a read threshold for the videodata read from the video zone of the optical disc 28, suggesting thatlarge volumes of data are being transferred. The hook driver 26 checks avideo data log for this purpose. If the answer is no, the hook driver 26simply logs in the video data log in step 726 the amount of data readfrom the video zone and proceeds to step 706.

However, if the hook driver 26 establishes in step 724 that the readthreshold has been exceeded, it proceeds to step 728 and reviews thelogs already mentioned for the write data and for the read bonusmaterial data and enquires whether a second threshold derived from theselogs has been exceeded. This second threshold is set to be thedifference of a write threshold for write data in the write data log anda read threshold for the amount of read bonus material data in the readbonus material data log, and signifies that a given greater amount ofdata has been written by the process to the hard disk 16 than relatessimply to the bonus material. Thus, this second threshold effectivelyrepresents a video data write threshold. If the answer to the enquiry ofstep 728 is no, the hook driver 26 proceeds to step 726 and logs in thevideo data log the amount of data read from the video zone.

On the other hand, if the answer to the enquiry of step 728 is yes, thehook driver 26 proceeds to step 730 and enquires whether a thresholdratio has been exceeded. This threshold ratio is the ratio of thedifference of the current amount of write data in the write data log andthe current amount of bonus material data read in the read bonusmaterial data log to the current amount of data in the video data log,and signifies that the amount of video data being written is sufficientto indicate ripping rather than merely, for example, analysis of thevideo material on the optical disc 28. If the answer to the enquiry ofstep 730 is yes, the hook driver again proceeds to step 732 and sets aflag indicating the process is permanently blocked. If the answer to theenquiry of step 730 is no, the hook driver 26 proceeds to step 726 andlogs the amount of video data read from the video zone of the opticaldisc 28.

After setting the process blocked flag in step 732, the hook driver 26next proceeds to step 722 and modifies the original SCSI request beforepassing it to the optical drive 20 in step 706.

The assumption here is that in the event of ripping, the volume of datatransferred will exceed both a read threshold and a write thresholdwhereas, in the event of normal playback, the read threshold may beexceeded but the write threshold will not be exceeded. Therefore, if theanswer to the enquiry of step 728 is a yes, indicating that the videodata write threshold has been exceeded, the hook driver 26 sets the flag“blocked equals true” for the current process. This flag indicates thatin the view of the hook driver 26, a ripping operation is taking placerather than normal playback and so the hook driver then modifies theSCSI request in step 722. Likewise, if the hook driver 26 discovers instep 732 that the ratio of read threshold to the difference of the writethreshold and the amount of bonus data read has been exceeded, it againsets the flag “blocked equals true” and modifies the original SCSIrequest on the assumption that ripping is taking place. Suchmodification may involve for example preventing the identified processfrom having further access to the optical disc 28 in the optical drive20 or preventing further copying from the optical disc 28 by preventingfurther writing or rendering the returned data useless.

In order to ensure the accuracy of the authentication and prevent afalse assessment of ripping, the read and write thresholds are set at arelatively high level. This means that a certain amount of data may becopied before a decision is taken to prevent further copying, and forexample several tens of megabytes may have been transferred between theoptical drive 20 and the target storage device 16 by the time thatripping is detected. However, for a typical DVD 100 megabytes stillrepresents only about 3 minutes of content and permitting a user to ripthis amount of copy protected video material is not significant in termsof the overall length of video content on the DVD, especially if itensures that the hook driver 26 does not interfere with normal playback.

It will be appreciated from the description of the embodiment shown inFIG. 7 that the hook driver 26 will effectively be invisible to SCSIrequests unless the optical disc 28 includes a fingerprint indicatingthat it is protected against copying and, in addition, a write processexceeds a predetermined write threshold.

A second embodiment of authentication device 64 is illustrated in FIG.12 and is based on an evaluation of a navigation path employed duringthe reading of data on the optical disc 28. In order to appreciate thisembodiment, it is necessary to understand the data structure provided onan optical disc 28, and also the navigation paths that will be employedfor reading the data on the optical disc 28. Therefore, a particularexample of the structure of data provided on a DVD will be describedfirst with reference to FIGS. 8 and 9, and the navigation paths takenrespectively by a legitimate player 30 and by two different kinds ofripper 32 for such a data structure will be described. next withreference to FIGS. 10 and 11.

Referring first to FIG. 8, the data provided on a DVD comprises controldata for managing reading of the DVD, ie for determining the navigationpath for reading the data on the DVD, and content data comprising themain content on the DVD. The DVD 28 shown in FIG. 8 is a simple videoDVD including an initial program chain (PGC) 800, which is normallyplayed first and which indicates the navigation path to be followed. Avideo manager (VMG) 802 contains various information data and includes atitle menu 804 having a main menu 806. The DVD also includes two videotitle sets (VTSs) 808 and 810, each again including information files.VTS1 808 includes a single title 812 containing the usual copyrightwarnings. VTS2 810 includes a first title 814 comprising the title for amain movie on the DVD and a second title 816 comprising a title for ashort video clip, such as a logo, or for a couple of frames of silentblack video.

Each of the titles 814, 816 includes one or more program chains (PGCs)818, 820 respectively. The PGC 818 of title 814 includes a number ofindividual programs 822, such as PG1, PG2 etc. . . . , which aretypically arranged to be played in sequence. Each of the programs 822has at least one pointer 824 addressing a particular part of acorresponding video object set 826. Each video object set 826 is dividedinto a number of cells 828, such as cell 1/1, cell 1/2 etc. . . .Likewise, the program chain 820 also has a program 830, such as PG1,having a pointer 832 to a particular part of the video object set 826,in this instance to a cell 834, such as cell 2/1.

The navigation sequence resulting from the navigation structure of FIG.8 is shown in FIG. 9. After loading the DVD 28 into the optical drive20, VTS1 808 and title 812 including the copyright warnings arepresented first. After this, the main menu 806 of the main title 804 ispresented, and if a play button 836 on the main menu 806 is activated,the navigation sequence proceeds to the title 816 in VTS2 810 and thelogo or other content included in cell 834. Next, the navigationsequence proceeds to the title 814 and plays the main content or movieof the DVD, following which the navigation sequence reverts to the mainmenu 806.

It is to be noted from FIG. 8 that the presentation data for the title816 is physically located on the DVD 28 after the presentation data forthe main title 814. Thus, as shown in FIG. 9, a legitimate player 30will first access the presentation data for title 816 by accessing cell834 at the end of the video object set 826 and will then jump back to aprevious physical location on the DVD 28 to access the presentation datafor the main title 814 by accessing the cells 828 of the video objectset 826. By contrast, a ripper would access the different files on theDVD in a linear manner or would access the information files first andthen, after selecting the main title, would access the presentation datafor the main title. Furthermore, a ripper would access the presentationdata for the main title 814 before the presentation data for title 816.This may best be understood from FIGS. 10 and 11.

FIG. 10 shows the navigation path of a legitimate player 30, indicatinghow the information files containing respectively the control data ornavigation information and the content data or video information areaccessed by the player. As shown, the player 30 first accesses thecontrol data or navigation information 1002in the VMG 802, and then VTS1808, the VMGM_VOBS within the VMG 802 and finally VTS2 810, according tothe navigation path defined by the navigation structure on the DVD Videoshown in FIG. 9. When accessing VTS2 810, the player is directed firstto the video object 834 comprising the cell 2/1 and next to the videoobjects 828 comprising the cells 1/1, 1/2 etc.

Turning to FIG. 11, this shows the navigation paths taken respectivelyby a first ripper 32 accessing the DVD sector by sector or file by fileand a second ripper 32 accessing the information files to obtain thetitle information first and then accessing the content data for thetitle selected for ripping, supposedly the main title. Such a ripper isknown as an “IFO parsing” ripper. As shown in FIG. 11, the sector bysector or file by file ripper 32 simply works its way through all of thefiles of the video manager 802, the VTS1 808 and the VTS2 810 inphysical sequence on the DVD. By contrast, the IFO parsing ripper 32accesses first the control data 1002 of each of the video manager 802and the VTS1 and VTS2 808, 810, and then proceeds next to access thevideo object 828 for the main title 814. In both cases, the ripper 32follows an entirely different navigation path from that of thelegitimate player 30 and accesses the video object 834 comprising thecell 2/1 after accessing the video object 828 comprising cells 1/1, 1/2etc. . . . or does not access the video object 834 at all.

The second embodiment of authentication device 64 illustrated in FIG. 12serves for monitoring such deviations in navigation path and forcontrolling access to the DVD accordingly. This embodiment is based onthe data and navigation structures shown in FIGS. 8 to 11.

The second embodiment of authentication device 64 shown in FIG. 12monitors access to the video objects 828, 834 of the DVD 28 in order tocheck for ripping. The hook driver 26 receives SCSI requests in step1200 and in step 1202 enquires whether the DVD is copy protected. If theanswer is no, the hook driver 26 simply forwards the SCSI request to theoptical drive 20 in step 1204. On the other hand, if it is establishedthat the DVD is copy protected, the hook driver 26 proceeds to step 1206and from the disc fingerprint establishes that the video object 834,comprising cell 2/1, should be read before the video object 828,comprising cells 1/1, 1/2 etc., and obtains the locations for cell 1/1and cell 2/1.

Next, the hook driver 26 proceeds to step 1208 and enquires whether theSCSI request that has been received is a read request. If the answer isno, the hook driver 26 proceeds to step 1204 and simply forwards therequest to the optical drive 20 as before. If, however, the answer is ayes, the hook driver 26 obtains the ID for the process intending to usethe DVD 28 in step 1210. The hook driver 26 proceeds to step 1212 andchecks whether the flag “blocked equals true” has already been set forthis process. If the answer is no, the hook driver 26 proceeds to step1214 and writes in the memory 14 the physical sector address of the discsector requested in the read request and the process ID for the processfrom which the SCSI request originated. The hook driver 26 then proceedsto step 1216 and checks whether the requested sector was in cell 1/1. Ifthe answer is no, the hook driver simply passes the request to theoptical drive 20 in step 1204 as before. If, on the other hand, theanswer to the enquiry of step 1216 is yes, the hook driver 26 enquiresin step 1218 whether cell 2/1 has already been accessed. If the answeris yes, once again the hook driver 26 simply forwards the request to theoptical drive 20 in step 1204. However, if the answer to the enquiry instep 1218 is no, indicating that the current read request hasendeavoured to access cell 1/1 without first accessing cell 2/1, thenthe hook driver sets the flag “blocked equals true” for the presentprocess in step 1220. When the flag “blocked equals true” is set, eitheras established in step 1212 or as the outcome of step 1220, the hookdriver 26 proceeds to step 1222 and modifies the original SCSI request,for example to prevent further access to the DVD or to prevent copyingfrom the DVD 28, before passing the modified request to the opticaldrive 20 in step 1204.

The embodiment of authentication device shown in FIG. 12 is designed todetect both sector by sector/file by file rippers and IFO parsingrippers, neither of which would access cell 2/1 before cell 1/1 withinVTS2 810. It is of course to be appreciated that the authenticationdevice 64 of FIG. 12 is based on a particular example of DVD given inFIGS. 8 to 11, and that it would be appropriately modified in anyinstance to suit the particular data and navigation structures on aparticular optical disc. It is also to be appreciated that alternativenavigation path authentication structures are possible.

A third embodiment of authentication device 64 is shown in FIG. 13 andis designed for detecting whether the correct navigation path on anoptical disc 28 is employed, based on the decryption of contentscrambling system (CSS) keys possessed by both the player 30 and theoptical disc 28 for encrypting information for controlling playback ofthe optical disc 28. The process starts in step 1300 when the hookdriver 26 starts to monitor the way in which CSS decryption is performedin response to a read or write request from the user application 44. Forsimplicity, it will be assumed that the request is a read request butthe process would be similar in the case of a write request. The hookdriver 26 proceeds to step 1302 and enquires whether the application 44validates a complete set of authentication grant IDs (AGIDs) forauthenticating a player 30 for video playback. If the answer is yes, thehook driver 26 proceeds to step 1304, but if the answer is no, the hookdriver stops the reading process in step 1306 on the assumption thatripping is taking place. In step 1304, the hook driver 26 enquireswhether the application is performing a valid CSS authentication. If theanswer is no, the application proceeds again to step 1306. However, ifthe answer is yes, the hook driver 26 proceeds to step 1308 and enquireswhether the application is reading a playback authentication keyprovided on the optical disc 28 using a correct bus key provided in theplayback software. If the answer is no, the hook driver 26 advances tostep 1306 and if the answer is yes the hook driver proceeds to step1310. In step 1310, the hook driver 26 enquires whether the applicationis reading a title key on the optical disc 28 representing the videotitle using the correct bus key in the playback software. If the answeris no, the hook driver 26 advances to step 1306 and if the answer ifyes, the hook driver 26 proceeds to step 1312. Here, the hook driver 26checks whether the application reads the title key from the correctsector of the optical disc 28. Again, if the answer is no, the hookdriver 26 advances to step 1306. On the other hand, if the answer tostep 1312 is yes, the hook driver 26 assumes that the player 30 is alegitimate user in step 1314 and allows playback to continue.

A fourth embodiment of authentication device is shown in FIG. 14 formonitoring the frequency of the reading requests sent to the opticaldrive 20 and for controlling access to the optical disc 28 accordingly.In this fourth embodiment, the hook driver 26 receives SCSI requests instep 1400, and in step 1402 checks the fingerprint on the optical disc28 and establishes whether the disc is copy protected. If the answer isno, the hook driver 26 simply forwards the request to the optical drive20 in step 1404. If, however, the answer is a yes, the hook driver 26proceeds to step 1406 and enquires whether the SCSI request is a readrequest. If no, the hook driver 26 forwards the request to the opticaldrive 20 by way of step 1404 as before. If the outcome of step 1406indicates that a read request has been received, the hook driver 26proceeds to step 1408 and obtains the ID for the process intending touse the optical media 28.

Next, in step 1410, the hook driver 26 enquires whether the flag“blocked equals true” has already been set for this particular process.The hook driver 26 proceeds to step 1420 if it notes that the flag“blocked equals true” is set for the present process. If the answer tostep 1410 is no, the hook driver 26 proceeds to step 1412 and writes inthe memory 14 the physical sector address of the sector on the opticaldisc 28 which has been requested in the read request, as well as thetime of the request. The hook driver 26 proceeds to step 1414 and checksfrom the recorded times of previous read requests whether the readrequest frequency for this process has exceeded a frequency threshold.If the answer is no, the hook driver 26 passes the read request to theoptical drive 20 by way of step 1404. If the answer is yes, on the otherhand, the hook driver 26 verifies in step 1416 whether the last block ofsectors read by the present process is composed of consecutive sectors.If the answer is no, the hook driver 26 proceeds to step 1404 andforwards the request to the optical drive 20. However, if the answer isyes, the hook driver 26 sets the flag “blocked equals true” for thepresent process in step 1418 and proceeds to step 1420. In step 1420,the hook driver 26 modifies the original SCSI request, for exampleeither to prevent further access to the optical disc 28 or to preventfurther copying of the optical disc 28, and then passes the modifiedrequest to the optical drive 20 by way of step 1404.

The fourth embodiment shown in FIG. 14 is based on the assumption that alegitimate player 30 reads sectors on the optical disc 28 at a ratedesigned to maintain sufficient information in its playback bufferswhilst rendering video, audio and sub-picture information available forpresentation to the viewer. By contrast, the ripper 32 will attempt toread each of the sectors comprising a particular cell as quickly aspossible in order to shorten the ripping time. Furthermore, if a player30 is scanning at high speed, the player will tend to skip certainsectors, whereas the ripper will typically attempt to read all theinformation in each cell. Therefore, by combining an evaluation ofreading frequency with an evaluation of reading order, it can beestablished whether the reading process is that of a legitimate player30 or that of a ripper 32.

It is possible, in a variation of the FIG. 14 embodiment, to omit theevaluation of reading order altogether and simply evaluate readingfrequency. In this instance, step 1416 would be omitted from the flowsequence illustrated in FIG. 14 and instead the sequence would passdirect from step 1414 to step 1418 in the event that the enquiry of step1414, as to whether the read request frequency threshold had beenexceeded, yielded the answer yes.

Various examples of the present invention have been described above. Itwill be appreciated that a number of modifications are possible withinthe scope of the invention.

For example, although four different versions of the authenticationdevice 64 have been discussed, it will be appreciated that othervariations may be employed. Further, the described authenticationdevices 64 may be employed individually or in combination in anyparticular hook driver 26 according to the circumstances.

In the case of an authentication device 64 that monitors patterns ofbehaviour, such as deviations in the navigation path employed foraccessing data on an optical disc 28, it will be appreciated that thedescribed patterns may be monitored by the device 64 separately or inconjunction, or indeed in conjunction with other such patterns, tocreate a more sophisticated behavioural model of the device.

A particular feature of the present invention is that the hook driver 26is effectively designed to be invisible to SCSI requests that arenormally legitimate. The described embodiments are also designed to beinvisible to optical media that do not possess a fingerprint indicatingthat the medium is copy protected.

Further, the described embodiments all check whether a newly insertedoptical medium has a fingerprint indicating that the medium is to beprotected against copying, and the hook driver 26 only implements itsfunctions in those instances. It is equally possible for the inventionto be employed in every case whether or not a fingerprint is present.

Furthermore, the described hook driver 26 is designed primarily tomonitor reading requests, although in further embodiments it is possiblefor the hook driver 26 to be designed to monitor other requests insteador as well.

The embodiments described above are all for the purposes of protectingoptical media against copying. It will be appreciated that the inventionmay alternatively or in addition have other applications. For example,once a user or process has been authenticated by the authenticationdevice 64, the device may permit or provide access to further functions,such as a legitimate copy process or an online store offering forexample soundtrack files, games or other special offers.

1. A method for monitoring and controlling access to data on a computerreadable medium, comprising: intercepting communications between anapplication program and a media drive; monitoring write requests issuedby the application program to the media drive and logging an amount ofdata written to a data storage unit in response to the write requests;monitoring read requests issued by the application program to the mediadrive and logging an amount of data read from a video zone on a computerreadable medium in response to the read requests; modifying readrequests from the application program to the media drive after thelogged amount of data read from the video zone exceeds a read threshold,the logged amount of data written to the data storage unit exceeds awrite threshold, and a ratio including the logged amount of data writtento the data storage device and the logged amount of data read from thevideo zone that indicates ripping is taking place; and sending themodified read requests to the media drive.
 2. The method according toclaim 1, further comprising: logging an amount of data read from otherthan the video zone on the computer readable medium in response to theread requests; and calculating a difference between the logged amount ofdata written to the data storage unit and the logged amount of data readfrom other than the video zone, wherein the logged amount of datawritten to the data storage unit is determined to exceed the writethreshold if the calculated difference is greater than the writethreshold and ripping is determined to be taking place if a ratio of thecalculated difference and the logged amount of data read from the videozone is greater than a threshold.
 3. The method according to claim 2,wherein the read threshold is in the range of 10 megabytes to 10gigabytes.
 4. A computer system comprising: a media drive having acomputer readable medium storing digital content; a data storage unit;and a processor adapted to execute an application program and a devicedriver, wherein the device driver intercepts communications between theapplication program and the media drive; monitors write requests issuedby the application program to the media drive and logs an amount of datawritten to the data storage unit in response to the write requests;monitors read requests issued by the application program to the mediadrive and logs an amount of data read from a video zone on the computerreadable medium in response to the read requests; modifies read requestsfrom the application program to the media drive after the logged amountof data read from the video zone exceeds a read threshold, the loggedamount of data written to the data storage unit exceeds a writethreshold, and a ratio including the logged amount of data written tothe data storage device and the logged amount of data read from thevideo zone that indicates ripping is taking place; and sends themodified read requests to the media drive.
 5. The computer systemaccording to claim 4, wherein the device driver logs an amount of dataread from other than the video zone on the computer readable medium inresponse to the read requests, calculates a difference between thelogged amount of data written to the data storage unit and the loggedamount of data read from the other than the video zone, use thecalculated difference for determining whether the logged amount of datawritten to the data storage unit exceeds the write threshold anddetermining whether ripping to taking place by, and use the calculateddifference in the ratio to determine whether ripping is taking place. 6.The computer system according to claim 5, wherein the read threshold isin the range of 10 megabytes to 10 gigabytes.